Day 5 | AI 輔助開發：如何讓 AI 幫你寫 ADK Agent 程式碼？

主張：coding agent 的訓練資料一定停在某個時間點，而 ADK 2.0 之後大約每週發版——直接叫它「幫我寫個 ADK agent」，很可能拿到一年前的舊語法。
讀完能做到：用官方提供的三條路，讓你的 coding agent 真正「知道」ADK 現在長什麼樣子，而不是憑訓練資料的記憶亂猜。

用 AI 幫忙寫 AI 應用很方便，但它給你的寫法，不一定跟得上最新版本。

如果你請 coding agent 幫你寫一個 ADK 2.0 的 Graph Workflow agent，它很可能會很自信地幫你覆寫一個 _run_async_impl()。程式碼看起來完全正常，agent 也照樣能啟動——但你寫進去的邏輯完全不會生效。官方文件講得很直白：2.0 的 Graph Workflow engine 會完全繞過這類 1.x 抽象方法的覆寫，靜默忽略（細節見 ADK 2.0 官方文件）。你不會收到任何錯誤訊息，只會納悶自己寫的邏輯為什麼像是憑空消失。

這不是 AI 不夠聰明，而是它的訓練資料一定停在某個時間點——Day 1 講過一個事實：ADK 2.0 之後大約每週發一個新版本。不管你用 Claude Code、Cursor、還是任何其他工具，它們的模型訓練資料在那之後可能已經改了好幾輪 API，_run_async_impl() 被靜默忽略就是活生生的例子。如果你直接請 coding agent「幫我寫一個 ADK agent」，它很可能會用一年前的舊語法回答你。

今天的主題，就是官方文件提供的三條路，讓你的 coding agent 真正「知道」ADK 現在的樣貌，而不是憑訓練資料的記憶亂猜。

路徑一：把 ADK 開發技能裝進你的 coding agent

Day 2 提過的 Agents CLI，除了拿來 scaffold 專案，它本身也是一組可以直接裝進 coding agent 的 skills。安裝指令跟 Day 2 一樣：

uvx google-agents-cli setup

裝好之後，你的 coding agent 會多出以下這些技能：開發生命週期與編碼指引、專案 scaffolding、評估方法與計分、Agent Runtime / Cloud Run / GKE 部署、Gemini Enterprise agent 發布、trace/logging 整合、以及 Python API 快速參考與文件索引。

裝好之後怎麼確認它真的生效了？依你用的工具，分別檢查：

1. Antigravity：
   進入 Antigravity 的編輯器後，直接問「What skills are available?」，就會直接列出來

2. Claude Code：
   直接在終端機輸入 claude /skills，或是進入 Claude Code 對話查詢 /skills。
3. Codex：
   進入 Codex 後，用 /skills 查詢現有的技能。

確認之後，直接用自然語言告訴你的 coding agent 想做什麼。官方給的示範 prompt：

Use agents-cli to build an agent that turns long text into short
bullet-point summaries

這句話下去之後會發生什麼事？官方文件描述得很具體：coding agent 會啟動 google-agents-cli-workflow 與 google-agents-cli-scaffold 這兩個 skill，反過來問你一些釐清問題（agent 要呼叫哪些工具、預期的輸入輸出長什麼樣、用什麼標準判斷它做得好不好），然後才動手用 google-agents-cli-adk-code 這個 skill 把程式碼寫進 app/agent.py。最終你拿到的是一個完整專案——agent 程式碼、測試、評估資料集一應俱全，跟 Day 2 講過的 Agents CLI 產出結構一致。

一個重要提醒：Agents CLI 的 skills 不是只給特定廠牌的工具用。官方文件明說它相容於任何支援 Agent Skills 規格 的 coding agent——多數工具用一個 /skills 指令，或是在設定面板裡就能看到已安裝的技能清單。

路徑二：接上 ADK 文件的 MCP Server

MCP（Model Context Protocol）是一種讓 AI 工具在執行當下即時存取外部資料或服務的通訊協定規格，細節見 MCP 官方文件。

第二條路更直接：讓你的 coding agent 能即時查詢官方文件，而不是仰賴訓練資料。這是透過一個叫 mcpdoc 的通用文件 MCP server 實現的，指向 ADK 官方文件站的索引檔。

如果你用 Claude Code，一行指令搞定：

claude mcp add adk-docs --transport stdio -- uvx --from mcpdoc mcpdoc --urls AgentDevelopmentKit:https://adk.dev/llms.txt --transport stdio

如果你用 Antigravity 或 Cursor，做法是打開 MCP 設定（Antigravity 在編輯器頂端的更多選單裡找 Manage MCP Servers → View raw config；Cursor 在設定裡的 Tools & MCP 分頁點 New MCP Server），把以下設定貼進去：

{
    "mcpServers": {
        "adk-docs-mcp": {
            "command": "uvx",
            "args": [
                "--from",
                "mcpdoc",
                "--with",
                "mcp>=1.28,<2",
                "mcpdoc",
                "--urls",
                "AgentDevelopmentKit:https://adk.dev/llms.txt",
                "--transport",
                "stdio"
            ]
        }
    }
}

官方文件也明講：任何支援 MCP 的工具都能用同一套設定，把上面的 JSON 片段套進對應工具的 MCP 設定檔就行。裝好之後，你的 coding agent 就能在寫程式碼之前，主動查詢 ADK 官方文件的最新內容，而不是憑印象重寫 API——這正是這個 vault 自己在維護時遵守的規則。

路徑三：直接餵完整文件索引

如果你不想透過 MCP server，官方文件本身就以 llms.txt 標準 提供機器可讀的版本：

官方文件特別強調：「These files are generated with every documentation update and are always up to date.」——這兩份檔案是跟著文件更新自動產生的，永遠是最新狀態。這也是這個 vault 的 raw/web/adk.dev/ 快照實際採用的方法：每一頁官方文件的 markdown 原文都是透過 llms.txt 索引批次抓下來的，能夠逐字保留程式碼與版本標記，而不是靠摘要工具轉譯後失真。

實戰示範：讓讀者親眼看到差異

想親眼確認差異，就重跑一次開頭那個 _run_async_impl() 的例子：

1. 在還沒接上任何文件來源的情況下，請 coding agent 寫一個用到 ADK 2.0 官方文件 才有的 Graph Workflow 範例——很可能它會生成 1.x 時代的階層式 agent 寫法，或是把 _run_async_impl() 之類 2.0 之後已經被靜默忽略的方法覆寫進去。
2. 接上路徑二的 MCP server 之後，重新問一次同樣的問題，對照兩次輸出的差異。

這個對照比單純介紹工具本身更有記憶點，也呼應了 Day 1 埋下的伏筆：ADK 的版本標記與破壞性變更，不是嚴謹癖，而是這個框架現階段真實會咬人的地方。

第一篇的收尾

到今天為止，新兵入伍篇的五天走完了一圈：認識了 ADK 2.0 的設計哲學（Day 1）、建好開發環境並跑起第一個 agent（Day 2）、學會定義 agent 的三個核心成分與模型接入方式（Day 3）、掌握了開發期的視覺化工具（Day 4）、也知道怎麼讓 AI 輔助自己的開發流程而不被過時資訊誤導（Day 5）。

明天開始進入第二篇：給 agent 真正的行動力，打破語言模型原生的能力邊界。